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1.  Introduction 


i  '  ■  p ; 


■^he  original  version,  of  the  Constructive  Cost  Model  (COCOMO)  [Boehm, 
1981]  was  calibrated  to  56  software  development  projects,  and  validated  on  7 
subsequent  projects.  On  these  projects,  the  COCOMO  devalopment  effort 
estimates  were  accurate  within  20%  of  the  project  actuals,  about  70%  of  the 
time. 

Subsequently.  COCOMO  has  oone  approximat3l>  as  woll  on  most 
carefully  collected  sets  of  project  data  [Eoefim,  1905;  Jo'-a.n,  1985;  Goudy, 

1987].  In  some  cases,  COCOMO  has  exhibited  a  systomat;  '  bias,  but  has  done 
approximately  as  well  once  recalibrated  to  the  specific  env.,  ment  [Boehm, 
1985;  Miyazaki' Mori,  1985;  Marouane-Mili,  1989].  !l  should  be  noted  that  there 
are  also  some  sets  of  project  data'  for  which  COCOMO  has  been  considerably 
less  accurate  [Kemerer,1987;  Martin,  1988]. 

Recently,  three  software  development  approaches  have  motivated  the 
development  of  a  revised  version  of  COCOMO:  ihc  use  of  the  Ada  programming 
language,  the  use  of  incremental  develOMnert,  and  the  use  of  an  Ada  process 
model  capitalizing  on  the  st'engths  of  A  i»  'o  improve  the  efficiency  of  software 
development.  This  paper  presents  the  poitions  of  the  revised  Ada  COCOMO 
dealing  with  the  effects  of  Ada  a.nc  •  'da  process  m.odel. 

The  remainder  of  thi.s  s?'  .icn  of  the  paper  discusses  the  objectives  of 
Ada  COCOMO.  Section  ?  d.asc‘>jos  the  Ada  Proresr  Model  and  its  overall 
effects  on  software  deve:cpnrient  effort  and  schccule.  Section  3  presents  the 
structure  and  features  cf  7 da  COCOMO,. ana  d'scusses  the  rationale  behind  the 
changes  made  from  the  ear'ier  version  .Oi -10  (called  "standard 

COCOMO"  in  the  rarr  ainder  of  the  papi  rV  Staion  4  sunrimarizes  the  current 
status  of  Ada  COCOMO,  inriud'ng  its  vi.alit  ^tion  to  date  and  its  currently 
available  imolementations;  and  Sectio  i presents  the  resulting  conclusions. 


The  primary  objectives  of  the  Ada  COCOMO  development  activity  were 


schedules.  Some  early  studios  of  Ada’s  impact  on  software  cost  indicated  that 
some  of  the  cost  driver  factors  might  be  different  for  Ada  prdjects  than  for  other 
projects,  and  that  the  phase  distribution  of  cost  and  schedule  might  also  be 
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different  [Baskette,  1987].  We  , wished  to  determine  whether  this  was  the  case 
and  what,  if  any,  changes  needed  to  be  made  to  COCOWO  to  accommodate 
Ada  effects. 

•  Determine  the  effect  of  the  Ada  Process  Model  on  software 
development  costs  and  schedules.  The  Ada  Process  Model  exploits  some  key 
Ada  features  (particularly,  early  compiler-checkable  Ada  package  specifications 
and  commonality  of  design-language  and  programming-language  constructs), 
software  risk  management  techniques  [Boehm,  1989],  and  more  general  large- 
scale  software  engineering  principles  ~  to  provide  a  more  efficient  and 
controllable  process  model  for  software  development.  We  wished  to  reflect  the 
effects  of  this  Ada  process  model  in  Ada  COCOMO. 

« Incorporate  related  COCOMO  improvements.  Since  1981,  we  have 
found  several  effects,  primarily  due  to  new  technology,  which  have  led  to 
extensions  to  the  original  COCOMO  cost  drivers.  We  wished  to  incorporate 
these  effects  both  into  standard  COCOMO  and  into  Ada  COCOMO. 


2.  The  Ada  Process  Mode! 

Farliar  attempts  to  use  software  cost  estimation  insights  to  improve 
software  productivity  focused  on  improving  the  settings  of  software  cost  driver 
variables  (via  use  of  tools  and  modern  programming  practices,  interactive 
workstations,  removing  hardware  constraints,  etc)  and  on  reducing  the  amount 
of  code  one  chooses  to  develop  via  reuse,  fourth  generation  languages, 
requirements  scrubbing,  etc.)  [Boehm,  1987]. 


The  Ada  Process  Model  attempts  to  further  improve  software  pro.  iuctivity 
by  reducing  the  exponent  relating  the  size  of  the  software  product  to  the  amount 
of  effort  required  to  develop  it.  For  the  COCOMO  embedded  mode  ( 
representing  the  type  of  challenging,  real-time  software  projects  primarily 
addressed  by  Ada),  this  equation  is; 


MMnom  =  2.8  (KDSl)  T20  , 


where  MMnom  represents  the  number  of  man-months  required  to  develop  an 
average  or  nominal  software  product,  and  KDSl  represents  the  thousands  of 
delivered  source  instructions  in  the  product. 

.  -  ■ 

A. 

The  resulting  inefficiency  or  diseconomy  of  scale  can  be  seen  from  the  ' 
fact  that  doubling  a  product’s  size  will  increase  its  nominal  effort  by  a  factor  of 
(2)'!  -20  s  2.30.  The  major  sources  of  this  inettciency  are  the  effects  of  process  ‘ 
thrashing,  turbulence,  and  interpersonal  communication  overhead  brought  oii 
when  large  numbers  of  project  personnel  are  working  in  parallel  on  tasks  which  -  -  _ 
are  closely  intertwined,  incompletely  defined,  continually  changing,  and  not  well  :  ^ 

prepared  for  downstream  integration.  ,  -  -  - .  *  ^  ^ 
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The  primary  strategy  elements  the  Ada  Process  Model  uses  to  reduce 
these  inefficiencies  or  diseconomies  of  scale  are  to: 

•  Produce  compilable,  compiler-checked  Ada  package  specifications  (and 
,  body  outlines),  expressed  in  a  well-defined  Ada  Design  Language 

(ADL),  for  all  top-level  and  critical  lower-level  Ada  packages,  by  the 
project's  or  increment's  Preliminary  Design  Review  (PDR). 

•  Identify  and  eliminate  all  major  risk  items  by  PDR.  This  has  the  effect  of 
focusing  the  PDR  (and  other  early  reviews  as  well)  on  working 
demonstrations  of  prototypes  or  kernel  capabilities  rather  than  on  large 
amounts  of  paper. 

•  Lise  a  phased  incremental  developr^ent  approach,  with  the  requirements 
for  each  increment,  called  a  build,  stabilized  by  the  build's  PDR. 

These  three  conditions  minimize  project  diseconomies  of  scale  by 
eliminating  the  following  primary  sources  of  software  project  inefficiency  and 
turbulence: 

1.  Interpersonal  Communications  Overhead.  An  issue  requiring  the 
coordination  of  N  agents  requires  the  exercise  of  N(N-1)/2 
communication  paths.  The  Ada  Process  Model  minimizes  this  effect  by 
keeping  the  design  team  size  N  small  until  PDR,  and  by  establishing  Ada 
■  package  specifications  for  unit-level  interfaces  by  PDR,  thus  minimizing 
the  number  of  issues  the  larger  post-PDR  development  team  will  have  to 
coordinate. 


2.  Late  Rework.  Even  with  rigorous  package  specifications,  a  project  will 
lapse  into  turbulence  If  the  resolution  of  a  high-risk  "architecture  breaker" 
problem  requires  redefinition  of  many  of  the  package  specifications. 
Eliminating  such  risk  items  by  PDR  ensures  that  the  project  may  proceed 
efficiently  with  its  initially-determined  package  specifications. 

3.  Unstable  requirements.  Even  with  rigorous  package  specifications  and 
no  post-PDR  risk  items,  a  project  will  lapse  into  turbulence  if  there  is  a 
continuing  stream  of  requirements  changes  Impacting  the  definition  of 
the  package  specifications.  Simply  raising  the  threshold  of  allowable 
requirements  changes  can  reduce  this  turbulence  considerably. 
Incremental  development  reduces  the  turbulence  effects  even  further  by 
reducing  the  amount  of  software  under  development  at  any  given  time, 
and  by  enabling  the  deferral  of  requirements  changes  to  downstream 
increments. 


An  overview  of  the  Ada  Process  Mode!  is  shown  as  Rgure  1.  Additional 
features  of  the  Ada  Process  Model  include  the  use  of: 

4.  Small  up-front  system  engineering  and  design  teams,  with  expertise  in 
software  architecture,  Ada,  and  the  applications  domain,  Such  people 
are  a  software  project’s  scarcest  resource.  The  Ada  Process  Model 
optimizes  their  contribution,  and  by  providing  validated  package 
specifications  to  the  larger  number  of  later  developers,  allows  these 
positions  to  be  staffed  by  more  junior  people. 

5.  A  project  risk  management  plan  to  determine  the  approach  for 
eliminating  risk  items  by  PDR,  and  alee  to  determine  the  sequence  of 
development  increments.  Early  increments  focus  on  devc  :pment  of 
"executing  architecture  skeletons"  to  ensure  that  critical  system  nuclei  are 
satisfactorily  implemented  early.  They  also  focus  on  prototypes  to 
eliminate  risks  associated  with  user  interface  uncertainties,  critical 
algorithms,  or  incorporation  of, state-of-the-art  computer  sri-nce 
capabilities.  Middle  increments  flesh  out  the  higher-priority,  better- 
understood  product  capabilities.  Later  increments  provide  additional 
furictions  as  their  needs  become  better  understood. 

6.  An  expanded  incremental  development  approach  Involving  lower 
increment  levels  within  each  build:  build  increments,  which  reflect  the 
planned  order  of  development  of  each  build;  and  component  increments, 
which  represent  increments  of  transition  between  Ada  Design  Language 
(ADL)  and  Ada  code  for  individual  components. 

7.  Intermediate  technical  walkthroughs  in  the  early  requirements  and 
design  phases.  These  focus  the  pre-walkthrough  effort  on  problem¬ 
solving  and  architecture  definition,  and  the  post-walkthrough  effort  on 
document  production. 

8.  Individual  detailed  design  walkthroughs  for  each  component  instead  of 
a  massive  Critical  Design  Review  (CDR)>  Instead,  an  efficient  CDR  is 
held  to  cover  the  highlight  issues  of  the  walkthroughs. 

9.  Continuous  integration  via  compiler  checking  of  Ada  package 
specifications  and  continuous  expansion  of  /fcL  statements  into  Ada 
code,  rather  than  beginning  integration  at  the  end  of  unit  test. 

10.  Bottom-up  requirements  verification  via  unit  standalone  tests,  build 
integration  tests,  and  engineering  string  tests,  so  that  the  demonstration 
of  requirements  satisfaction  has  been  mostly  done  by  the  end  of  system 
test. 

1 1 .  Well-commented  Ada  code  and  big-picture  design  information  instead 
of  massive  as-built  Software  Detailed  Design  Documents,  which  rapidly 
get  out  of  date  and  lose  their  maintenance  value. 


12.  A  set  of  automated  metrics  tightly  coupled  to  the  project's  Software 
Development  Plan  and  its  build  definitions.  Conventions  on  ADL  and  its  • 
expansion  into  Ada  code  enable  metric  tools  to  provide  detailed  visibility 
into  the  usually-obscure  code  development  process. 

The  resulting  Ada  Process  Model  can  be  and  has  been  used 
successfully  as  a  tailored  version  of  such  Government  standards  as  DoD-STD- 
2167.  This  was  done  initially  on  a  small  TRW-intemal  project,  and  is  currently 
underway  on  a  large  Air  Force  project:  the  Command  Center  Processing  and 
Display  System-Replacement  (CCPDS-R)  project.  CCPDS-R  is  currently  about 
24  months  into  its  36-month  development  schedule.  It  has  completed  3  of  its  5 
builds  (about  300,000  of  its  planned  500,000  lines  of  Ada),  and  has  met  all  of  its 
Ada  Process  Model  milestones  to  date.  More  details  on  the  Ada  Process  Model 
and  its  application  to  CCPDS-R  are  given  in  [Royce,  1989],  Although  the  model 
was  developed  for  use  on  Ada  projects  and  has  some  Ada-specific  features, 
many  of  its  features  can  be  applied  to  non-Ada  projects  as  well. 


Cost  and  Schedule  Implications  of  the  Ada  Process  Model 

Because  of  the  reduction  in  project  communications  overhead  and 
diseconomies  of  scale,  the  use  of  the  Ada  Process  Model  leads  to  an  overall 
reduction  in  project  effort.  The  overall  schedule  for  a  single-shot  development 
is  lengthened  somewhat,  but  the  use  of  incremental  development  means  that 
users  receive  their  initial  operating  capability  eaiiier.  The  phase  distribution  cf 
effort  and  schedule  also  changes.  Use  of  the  Ada  Process  Model  involves  more 
effort  and  schedule  for  requirements  analysis  and  design,  and  considerably 
less  for  code,  integration,  and  test. 

Ada  COCOMO  models  the  effect  of  the  Ada  Process  Model  in  terms  of  a 
reduction  in  the  nominal  effort  equation  exponent  of  1.20.  The  new  nominal 
effort  equation  takes  the  form: 

MMnom  “  2.8(KDSI)1-W+2:., 

The  parameter  X  measures  the  project’s  estimated  degree  of  compliance  with 
the  Ada  Process  Model  in  terms  of  four  parameters' 

•  The  percent  O''  the  design  that  has  been  expressed  as  compiler-checked 

Ada  package  specifications  and  body  outlines  by  PDR. 

•  The  percent  of  the  risk  items  that  have  bet#fi  eliminated  by  PDR. 

•  The  degree  to  which  the  requirements  have  been,  stabilized  by  PDR. 

•  The  team's  previous  experience  in  applying  the  Ada  Process  Model. 


r‘ 


If  a  project  is,  fully  compliant  with  the  Ada  Process  Model,  then  S  will  be 
0.00,  and  the  diseconomy' of  scale  exponent  will  be  1.04.  If  a  project  exhibits 
the  current  typical  hasty-PDR  symptoms,  then  S  will  bo  0.16,  and  the  exponent 
will  be  1 .20,  the  same  as  tor  the  current  COCOMC  embedded-mode  model. 
The  S  parameter  is  also  used  in  Ada  COCOMO  in  e.^tinating  the  development 
schedule  and  the  phase  distribution  of  effort  and  schedule. 


3.  Ada  COCOMO  Structure  and  Features 

This  Section  provides  the  information  necessary  to  use  the  essential 
portions  of  Ada  COCOMO  or  to  implement  them  in  a  computer  program. 

Section  3.1  summarizes  the  differences  between  Ada  COCOMO  and  standard 
COCOMO.  Section  3.2  provides  a  structural  overview  of  the  model's 
computations.  Section  3.3  provides  the  information  necessary  to  determine  the 
project's  Ada  Process  Model  S  parameter  and  to  determine  the  project's 
nominal  effort  estimate.  Section  3.4  provides  the  rating  scales  and  effort 
multipliers  for  the  Ada  COCOMO  cost  driver  variables.  Section  3.5  provides  the 
Ada  COCOMO  schedule  estimation  equation,  the  tabies  for  determining  the 
phase  distribution  Of  project  effort  and  schedule,  and  an  overviev/  of  the 
incremental  development  model.  Section  3.6  provides  an  example  comparing 
Ada  COCOMO  and  standard  COCOMO  estimates  on  two  sample  projects. 


3.1  Differences  Between  Ada  COCOMO  and  Standard  COCOMO 

Ada  COCOMO  has  three  categories  of  differences  from  standard 
COCOMO: 

a.  General  improvements  to  COCOMO.  which  can  be  incorporated  as 
improvements  to  standard  COCOMO  as  well.  These  comprise  a  wider 
range  of  ratings  and  effects  due  to  software  tools  and  turnaround  time; 
the  splitting  of  virtual  machine  volatility  effects  into  host  and  target 
machine  effects;  the  elimination  of  added  costs  due  to  schedule 
stretchout;  the  addition  of  cost  drivers  to  cover  effects  of  security- 
classified  projects  and  development  for  software  reusability;  and  the 
addition  of  a  model  for  incremental  development. 

b.  Ada-specific  effects,  including  reduced  multiplier  penalties  for  higher 
levels  of  required  reliabiliiy  and  product  complexity;  a  wider  range  of 
ratings  and  multipliers  for  programming  language  experience;  and  a  set 
of  Ada-oriented  instruction-counting  rules,  including  the  effects  of 
software  reuse  in  Ada. 

c.  Effects  of  using  the  Ada  Process  Model,  which  can  largely  be  adapted  to 
projects  using  other  programi  ling  languages.  Their  use  on  non-Ada 
projects  would  require  some  experimental  tailoring  of  standard 
COCOMO  to  accommodate  the  resulting  cost  and  schedule  effects. 
These  effects  include  the  revised  exponential  scaling  equations  for 


nominal  development  effort,  development  schedule,  and  nominal 
maintenance  effort;  the  extended  range  of  modern  programming 
practices  effects;  the  revised  ranges  of  analyst  capability  and 
programmer  capability  effects;  and  the  revised  phase  distributions  of 
effort  and  schedule. 

The  remainder  of  standard  COCOMO  remains  the  same  as  it  was:  the 
overall  functional  form,  most  of  the  effort  multipliers,  the  software  adaptation 
equations,  the  activity  distribution  tables,  and  the  use  of  annual  change  traffic 
for  software  maintenance  estimation.  Standard  COCOMO  also  covers  all  three 
COCOMO  development  modes;  to  date,  there  is  only  an  Ada  COCOMO 
counterpart  of  the  COCOMO  Embedded  mode. 


3.2  Ada  COCOMO  Structural  Overview 

Rgure  2  provides  an  overview  of  the  Ada  COCOMO  steps  used  to 
estimate  software  development  costs  and  schedules.  The  first  step  uses 
estimates  of  the  software  size  in  thousands  of  delivered  source  instnjctions 
(KDSI)  and  the  Ada  Process  Model  S  factor  to  calculate  the  nominal  man-month 
estimate:  the  amount  of  effort  the  project  would  require  if  it  were  perfectly 
average  in  all  respects.  Step  2  involves  determining  the  cost-sensitive  ways  in 
which  the  project  is  different  from  average.  The  project  is  rated  in  terms  of  1 8 
cost  driver  attributes;  the  ratings  are  used  to  detennine  a  set  of  1 8  effort 
multipliers;  these  are  multiplied  together  and  applied  to  the  nominal  man-month 
estimate  to  produce  the  project’s  estimated  effort  in  man-months.  At  this  point,  a 
cost  per  man-month  figure  may  be  applied  to  determine  the  project’s  cost  in 
dollars  or  other  currencies. 

Step  3  estimates  the  project’s  development  schedule  (from  its  software 
requirements  review  to  its  software  acceptance  test)  as  a  function  of  its 
estimated  man-months  and  its  Z  factor.  Step  4  estimates  the  phase  distributipn 
of  effort  and  schedule  from  a  set  of  tables  of  distribution  percentages  vs  size.  In 
Step  5,  the  effects  of  incremenbi  development  can  be  estimated  by  repeatedly 
applying  Steps  1-4  to  the  overall  project  and  to  the  individual  increments,  and 
appropriately  phasing  the  increments’  estimated  budgets  and  schedules. 


3.3  The  Ada  Process  Model  T.  Factor 

Rgure  3  shows  the  rating  scale  used  to  determine  a  project's  Add 
Process  Model  Z  factor.  Each  of  the  four  elements  has  a  rati.ng  scale  from  0.00 
to  0.05;  the  ratings  for  each  element  are  added  together  to  define  Z-  The  first 
element,  Experience  with  the  Ada  Process  Model,  is  easier  to  rate  in  advance  of 
the  project  than  the  others:  one  determines  the  degree  of  experience  with  the 
model  of  the  project's  key  personnel,  and  uses  this  to  determine  tills  element's 
numerical  contribution  to  Z. 
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For  the  other  elements.  Figures  4-6  provide  a  more  detailed  set  of  rating 
scales  which  can  be  applied  early  in  the  project's  life  cycle.  Let  us  iook  at  an 
example  project  in  terms  of  Rgu*^  4,  which  prcvides  several  criteria  for 
estimating  a  project's  likely  level  of  desig.i  thoroughness  by  PDR. 

Suppose  that  the  example  pmject  has  a  relatively  sketchy  risk 
management  plan,  sc  that  the  best  that  could  be  claimed  in  Row  1  of  Figure  4 's 
"some*  compatibility  with  it  (an  0.03  rating).  On  the  other  hand,  the  project  ha  j 
25Vw  of  its  development  schedule  devoted  to  the  preliminary'  aesign  ^  base  (an 
0.02  rating);  100%  of  the  necessary  architects  available  (an  0.01  rating);  and 
good  front-end  tool  support:  a  solid  Ada  compiler,  but  no  related  grapnic 
architecture  and  design  aids  (an  0.02  rating).  The  level  of  uncertainty  in  key 
architecture  drivers  could  be  rated  as  either  “some’  (0.02)  or  "considerable" 
(0.03),  but  since  the  other  items  average  out  to  0.02,  using  an  0.02  rating  for  the 
Design  Thoroughness  by  PDR  element  would  be  reasonable. 

The  project  would  use  Figures  5  and  6  in  a  similar  fashion  to  determine 
Z  ratings  for  these  elements.  Suppose  that  the  Risk  Elimination  by  PDR  rating 
from  Rgure  5  was  0.03,  the  Requirements  Volatility  rating  from  Rgure  6  was 
0.01 ,  and  the  rating  for  Ada  Process  Model  familiarity  was  0.02.  Adding  these 
ratings  to  the  Design  Thoroughness  rating  of  0.02  gives  an  overall  £  factor  of 
0.08.  Therefore,  the  nominal  effort  equation  exponent  for  this  project  would  oe 
1 .04  +  0.08  =  1 .1 2;  the  resulting  equation  is: 

MMnom  =  2.e(KDSI)  ^-■'2. 

The  data  at  the  bo^t'im  of  Figure  3  show  how  significant  an  influence  the 
£  factor  has  upon  software  costs.  For  a  nominal  100,000  instruction  product,  a 
£  =  0.08  project  is  estimated  to  require  487  man-morths  for  development.  A  £ 
=  0.16  rating  would  incroase  this  estimate  to  703  MM,  while  a  decrease  to  £  = 
0.00  would  decrease  the  estimated  effort  to  336  MM. 

While  the  overall  effect  of  the  £  factor  is  significant,  it  does  not  introduce 
instabilities  in  Ada  COCOMO.  A  change  of  one  rating  level  on  one  of  the  rating 
scales  in  Rgure  3  corresponds  to  a  change  of  about  5%  in  the  estimated 
development  effort  for  a  1 00  KDSI  product. 


3.4  Ada  COCOMO  Cost  Driver  Variables 

The  differences  between  the  Ada  COCOMO  cost  driver  variables  and 
their  eeX^OMO  counterparts  are: 

*  Two  new  variables  have  been  added:  Required  Reusability  (RUSE)  and 
Classified  Security  Application  (SECU). 

•  The  Virtual  Machine  Volatility  (VIRT)  variable  has  been  split  into  host 
volatility  (VMVH)  and  target  volatility  (VMVT/  effects. 


•:2.  OVIODOO 


•  Several  variables  have  new  effort  multipliers  and/or  new  rating  levels. 

•  Complementary  changes  have  been  incorporated  in  the  Ada  COCOMO 
maintenance  estimation  model. 

Rgure  7  shows  the  overall  comparison  between  the  COCOMO  and  Ada 
COCOMO  cost  driver  multiplier  ranges, for  the  Intermediate  level  of  COCOMO. 
The  corresponding  numerical  multipliers  for  Intermediate  Ada  COCOMO  are 
given  in  Table  1.  The  corresponding  multipliers  and  rating  scales  for  Detailed 
Ada  COCOMO  and  the  maintenance  portion  of  Ada  COCOMO  are  available  in 
[Boehm-Royce,  1987];  within  the  confines  of  this  paper,  we  will  focus  on  the 
differences  in  Intermediate  Ada  COCOMO  and  their  rationale. 


New  Cost  Driver  V  riables 

1*he  Required  Reusability  variable  (RUSE)  has  been  added  to  address 
the  effects  of  developing  software  for  reuse  in  future  situations.  The  rating 
scales  and  their  corresponding  effort  multipliers  (E.M)  are: 

RUSE  Rating  E  M  Rating  Description 

Nominal  1.0  No  reuse 

High  1.10  Reuse  within  single-mis.sion  products 

Very  High  1 .30  Reuse  across  a  single  product  line 

Extra  High  1 .50  Reuse  in  any  application 

The  added  effort  for  more  general  reusability  levels  reflects  the  need  for 
more  generic  design  of  the  software,  more  elaborate  documentation,  and  more 
extensive  testing  to  ensure  confident  reuse  in  all  specified  situations:  The  cost 
of  incorporating  the  reusable  software  into  a  product  is  handled  in  the  same 
way  as  in  standard  COCOMO,  via  estimation  of  the  amount  of  adapted  software 
and  the  perce.nvages  of  change  required  in  its  design,  code,  and  integration  to 
incorporate  it  into  the  new  product. 

The  Classified  Security  Application  variable  (SECU)  has  been  adapted 
from  the  discussion  in  Chapter  28  of  [Boehm,  1981].  The  rating  scales  and 
effort  multipliers  are: 


Sl'QU  Rating  £M 


Rating  Description 


Nominal  1.0  Unclassified  Project 

High  1-10  Classified  (Secret  or  Top  Secret)  Project 


Host-Taroet  Effects 

The  increased  use  of  the  host-target  mode  of  software  development  has 
led  to  a  split  in  the  Virtual  Machine  Volatility  (VIRT)  cost  driver  variable  into  two 
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variables:  Virtual  Machine  Volatility  -  Host  (VMVH)  and  Virtual  Machine  Volatility 
-  Target  (VMVT).  The  rating  scales  and  corresponrRng  effort  multipliers  are: 


wmm 

VMVH*VM\r 

VIRT 

Low 

0.92 

0.93 

0.86 

0.87 

Nominal 

1.00 

1.00 

1.00 

1.00 

High 

1.09 

1.07 

1.17 

1.15 

Very  High 

,  1.17 

1.16 

1.36 

1.30 

Prod'y  Range 

1.27 

1.25 

1.53 

1.49 

The  Productivity  Range  is  defined  as  the  ratio  between  the  highest  and 
the  lowest  effort  multipliers  for  any  given  cost  driver  variable.  It  is  a  measure  of 
the  leverage  that  the  variable  has  on  software  development  costs.  The 
combined  productivity  range  for  VMVH  and  VMVT  is  slightly  higher  than  the 
corresponding  productivity  range  for  the  COCOMO  VIRT  variable.  This  reflects 
the  deeper  interaction  between  operating  system  services  and  Ada  programs 
(e.g.,  via  tasking  and  exceptions)  than  with  earlier  programming  languages. 


New  Effort  Multipliers:  Ada  Effects 

The  Ada  COCOMO  variables  Required  Reli^ility  (RELY),  Product 
Complexity  (CPLX),  Language  Experience  (LEXP),  and  Use  of  Modern 
Programming  Practices  (MODP)  have  different  multipliers  in  Ada  COCOMO 
than  in  standard  COCOMO  due  to  effects  of  the  Ada  programming  language. 

For  the  Nominal,  High,  and  Very  High  rating  levels  of  Reouired 
Reliability,  the  effort  multipliers  are  reduced  in  Ada  COCOMO.  "i  nis  is  due 
primarily  to  such  Ada  language  features  as  strong  typing,  tasking,  exceptions, 
and  packages,  which  prevent  many  classes  of  softv^e  errors  from  occurring, 
limit  the  side  effects  of  errors,  and  make  some  classes  of  errors  easier  to  find. 
The  comparison  with  standard  COCOMO  is  shown  below: 

RELY  Rating  Ada  COCOMO .  _  COCOMO  E.M 


Very  Low  0.75  0.75 

Low  0.88  0.88 

Nominal  0.96  1.00 

High  1.07  1.15 

Very  High  1.24  1.40 

ProcTy  Range  1.65  1.87 


For  Product  Complexity,  several  of  the  rating  levels  have  different  effort 
multipliers: 


GPLX  Rating  Ada  COCOMQ  COCOMO  E  M 


Very  Low 

0.73 

0.70 

Low 

0.85 

0.85 

Nominal 

0.97 

1.00 

High 

1.08 

1.15 

Very  High 

1.22 

1.30 

Extra  High 

1.43 

1.65 

Prod'y  Range 

1.96 

2.36 

The  Ada  COCOMO,  effort  multiplier  for  Very  Low  complexity  is  slightly  higher 
than  its  COCOMO  counterpart  due  to  the  extra  work  required  in  Ada  for  very 
simple  programs.  The  effort  multipliers  for  the  higher  rating  levels  are  lower 
than  their  COCOMO  counterparts  since  there  are  a  number  of  Ada  paradigms 
(tasking,  exceptions,  record  types,  access  types)  which  make  previously 
complex  programming  constructs  more  straightforward  to  implement. 

The  Programming  Language  Experience  variable  (LEXP)  in  Ada 
COCOMO  has  an  additional  rating  level  and  a  significantly  wider  productivity 
range  than  its  standard  COCOMO  counterpart.  The  comparison  is  shown 
below: 


LEXP  Ratino 

Ada  COCOMO 

COCOMO 1 

Very  Low 

1.26 

1.14 

Low 

1.14 

1.07 

Nominal 

1.00  , 

1.04 

High 

0.95 

0.95 

Very  High 

0.36 

Prod'y  Range 

147 

1.20 

The  Very  High  rating  corresponds  to  an  Ada  experience  level  of  at  least  6 
years.  The  main  reasons  for  the  difference  from  standard  COCOMO  is  that  Ada 
is  a  much  richer  and  more  complex  language  than  most  previous  languages. 
(An  exception  is  PLyi,  which  has  had  a  similar  widened  productivity  range  for 
LEXP  in  the  Jensen  model  [Jensen-Lucas,  1985]).  For  many  computer  program 
functions,  there  are  several  ways  to  implement  them  in  Ada,  each  with 
somewhat  different  side  effects  (e.g.,  branches,  case  statements,  loops,  tasking 
statements,  exceptions,  procedure  calls).  An  experienced  Ada  developer  can 
capitalize  on  this  richness  to  simplify  many  program  functions,  while  an 
inexperienced  Ada  developer  i.s  more  likely  to  choose  an  Ada  implementation 
with  harmful  side  effects  (performance  problems,  reliability  problems, 
modifiability  problems,  difficulties  in  handling  nonstandard  conditions,  or  just 
plain  errors). 

The  Ada  COCOMO  Use  of  Modem  Programming  Practices  variable 
(MODP)  has  a  slightly  different  set  of  effort  multipliers  than  standard  COCOMO, 


due  to  Ada's  improved  support  of  modem  programming  practices,  particularly 
modularity  and  information  hiding  [Parnas,  1979]  and  object-oriented 
development  [Booch,  1987].  The  resulting  comparison' is  as  follows: 


L&LeJiklsMUH 

Very  Low 

1.24 

1.24 

Low 

1.10 

1.10 

Nominal 

0.98 

1.00 

High 

0.86 

0.91 

Very  High 

0.78 

0.32 

Prod'y  Range 

1.59 

1.51 

For  maintenance,  MODP  is  treated  differently  In  Ada  COCOMO,  in  that 
MODP  ratings  are  used  to  determine  a  large  component  of  the  I  size-scaling 
factor,  rather  than  to  determine  effort  multipliers  as  a  function  of  size.  Details 
are  provided  in  [Boehm-Royce,  1987]. 


New  Effort  Multipliers:  Ada  Process  Model  Effects 

The  Ada  Process  Model's  emphasis  on  achieving  a  solid  and  stable 
architecture  for  the  software  product's  life-cycle  reduces  the  damage  that  less- 
capable  programmers  can  do  to  the  project.  But  it  also  places  a  heavy  reliance 
on  the  capability  of  the  analysts  to  create  such  an  architecture.  Thus,  Ada 
COCOMO  has  a  different  set  of  effort  multipliers  for  Analyst  Capability  (ACAP) 
and  Programmer  Capability  (PCAP)  than  standard  COCOMO.  The  Comparison 
between  full  use  of  the  Ada  Process  Model  (S=0.00)  and  standard  COCOMO  or 
non-use  of  the  Ada  Process  Model  is  as  follows: 

Rating  Full  Ada  P.M.  (1=0.00)  Std.  COCOMO  (2=0.16) 

■■  '  ' _ ACAP  PCAP _ ACAP-^I^CAP 


Very  Low 

1.57 

1.30 

1.46 

1.42 

Lov/ 

1.29 

1.12 

1.19 

1.17 

Nominal 

1.00 

1.00  , 

1.00 

1.00 

High 

0.80 

0.89 

0.86 

0.86 

Very  High 

0.61 

0.80 

0.71 

0.70 

Prod’y  Range 

2.57 

1.62  4.16 

2.06 

2.03 

Although  the  full  use  of  the  Ada  Process  Model  correlates  with  a  wider 
productivity  range  for  Analyst  Capability  and  a  narrower  productivity  range  for 
Programmer  Capability,  their  combined  productivity  range  is  essentially  the 
same  as  for  standard  COCOMO  (4.16  vs.4. 14). 

For  partial  use  of  the  Ada  Process  Model  (2  between  0.00  and  0.1 8),  one 
interpolates  between  the  values  of  ACAP  and  PC^AP  for  full  pse  and  non-use  of 


the  Ada  Process  Model.  For  example,  a  project  at  the  half-way  point  (S=0.08) 
with  Very  High  capability  analysts  and  programmers  would  use  the  following 
effort  multipliers: 


ACAP:  0.61  (0.08/0.16)  (0.71  -  0.61)  =  0.66. 
PCAP:  0.80 -h  (0.08/ 0.16)  (0  70 -0.80)  =  0.75. 


New  Effort  Multipliers:  General  Effects 

The  Ada  COCOMO  variables  Computer  Turnaround  Time  (TURN),  Use  of 
Software  Tools  (TOOL),  and  Required  Development  Schedule  (SCED)  differ 
from  their  standard  COCOMO  counterparts  due  to  general  technology  effects 
which  are  independent  of  Ada.  The  TURN  variable  has  an  additional  rating 
level  of  Very  Low,  reflecting  the  more  effective  exploitation  of  interactive 
software  development  as  compared  to  the  late  1 970's,  when  standard 
COCOMO  was  calibrated.  The  main  changes  are: 

•  Furnishing  every  software  project  person  with  an  interactive  terminal,  as 
compared  to  the  late-1970's  average  of  roughly  0.3  terminals  per  project 
person. 

•  Interactive  support  of  all  project  phases,  as  compared  to  primary  support 
of  the  code  and  unit  test  phase  in  the  late  1 970’s. 

The  resulting  comparison  of  TURN  effort  multipliers  is  as  follows: 

TURN  Rating  Ada  COCOMO  COCOMO  E.M 


Very  Low 

0.79 

Low 

0.87 

0.87 

Nominal 

1.00 

1.00 

High 

1.07 

1.07 

Very  High 

1.15 

1.15 

Prod'y  Range 

1.46 

1.32 

The  TOOL  variable  has  two  additional  rating  levels.  Extra  High  and  XX- 
High,  reflecting  more  fully  populated  and  integrated  tool  sets  than  were 
available  in  the  late  1970's.  The  Extra  High  level  reflects  a  partly  integrated  tool 
set,  using  a  Unix-level  (pipes  and  hierarchical  ASCII  filesjrtavei  of  tobi 
Interoperability.  The  XX-High  level  has  not  yet  been  fully  achieved  by  a 
software  engineering  environment  One  way  of  visualizing  its  level  of  capability 
is  that  it  would  provide  for  all  software  project  life  cycle  functions  the  level  of 
incremental  analysis  and  feedback  capability  that  the  current  Rational 
environment  provides  for  incremental  Ada  syntax  and  semantic  analysis. 

The  resulting  comparison  of  TOOL  effort  multipliers  is  as  follows: 


Very  Low 

1.24 

1.24 

Low 

1.10 

1.10 

Nominal 

1.00 

1.00 

High 

0.91 

0.91 

Very  High 

0.83 

0.83 

Extra  High 

0.73 

XX  High 

0.62 

Prod'y  Range 

2.00 

1.49 

The  SCED  variable,  has  been  changed  to  eliminate  the  effort  penalty 
associated  with  stretching  a  software  project's  schedule  beyond  the  "natural" 
schedule  estimated  by  the  Ada  COCOMO  schedule  equation.  This  branch  of 
the  effort-vs.-schedule  tradeoff  curve  has  been  a  point  of  difference  between 
software  cost  models.  The  SLIM  [Putnam,  1978],  Jensen  [Jensen-Lucas,  1983], 
and  Softcost  [Reifer,  1988]  models  incorporate  a  large,  unending  effort 
decrease  as  schedule  is  stretched;  the  standard  COCOMO  and  Price  S 
[Freiman-Park,  1979]  rnodels  have  incorporated  a  slight  effort  increase  as 
schedule  is  stretched.  The  rationale  in  Ada  COCOMO  for  keeping  the  High  and 
Very  High  schedule-stretch  multipliers  at  1.00  is  that  incremental  development 
has  not  been  observed  to  incur  a  cost  penalty,  if  the  incremental  strategy  has 
been  v/ell  planned  out  in  advance,  although  it  will  stretch  the  development 
schedule. 


The  remaining  COCOMO  cost  driver  variables  were  unchanged  in  Ada 
COCOMO,  reflecting  the  judgement  that  their  effort  multiplier  effects  were  highly 
indep^dent  of  the  use  of  Ada.  TheSe  were  Data  Base  Size  (DATA),  Execution 
Time  C  onstraint  (TIME),  Main  Storage  Constraint  (STOR),  Applications 
Experience  (AEXP),  and  Virtual  Machine  Experience  (VEXP).  An  overall 
summary  of  the  Ada  COCOMO  effort  multipliers  is  given  in  Table  1 . 


in  addition,  Ada  COCOMO  has  compatible  phase-spedfic  effort 
multipl  ers  for  implementing  the  Detailed  version  of  COCOMO,  and  counterpart 
changes  in  the  maintenance  effort  multipliers  for  the  Required  Reliability  (RELY) 
variable.  Details  are  provided  in  [Boehm-Royce,  1987]. 


3.5 


,  the  standard  COCOMO  embedded-mode  schedule  equation  is: 

Tdev  =  2.5  (MM)  0.32  , 

where  is  the  development  time  in  months  from  the  Software 
Requirements  Review  to  the  Software  Acceptance  Test,  and  MM  is  the 
estimated  development  effort  in  man-months.  The  corresponding  Ada 
COCOMO  schedule  equation  is:  .  , 

Tdev  =  3.o  (mm)  0.32+  0.21 , 

where  X  is  the  Ada  Process  Model  compliance  factor. 

The  revised  coefficient  and  added  X  factor  were  determined  from 
calibration  to  the  two  Ada  projects  onginally  used  to  calibrate  Ada  COCOMO. 
The  equation  has  also  been  a  good  fit  to  three  subsequent  Ada  projects.  The 
equation  indicates  a  longer  development  time  for  a  given  man-monih  level  due 
to  longer  early  schedule  investments  in  requirements  and  design  definition  and 
validation.  These  are  compensated  by  the  overall  reduction  in  man-months 
from  using  the  Ada  Process  Model,  and  by  the  use  of  incremental  development, 
which  p.'-ovides  an  initial  usable  increment  earlier  than  a  single-shot 
development  of  the  entire  product  can  provide. 


£t!ase-Di.§tribution.of.  Effort  .and  Scheduig 

The  Ada  Process  Model  requires  more  effort  and  schedule  in  the  early 
phases  of  software  development,  and  saves  considerably  more  effort  and 
schedule  in  the  later  phases.  This  Is  borne  out  by  the  comparison  of  phase 
distributions  in  Table  2  between  full  use  of  the  Ada  Process  Model  (X  =  0.00) 
and  non-use  of  the  Ada  Process  Model  ( the  standard  COCOMO  Embedded 
Mode,  or  X  =  0.16).  A  project  which  partially  complies  with  the  Ada  Process 
Model  would  therefore  interpolate  in  Table  2  to  find  its  phase  distribution  of 
effort  and  schedule.  Thus,  for  example,  a  128-KDSI  Embedded  Mode  project 
with  a  X  of  0.08  would  have  phase  distributions  halfway  between  the  table 
entries  for  a  128-KDSI  project:  e.g.,  20.5%  of  its  effort  and  37,5%  of  its  schedule 
in  the  Product  Design  phase. 

The  use  of  the  Ada  Process  Model  has  also  changed  the  definition  of 
two  of  the  major  milestones  defining  the  phase  eridpoints.  Table  3  shows  the 
revised  definitions  of  the  Software  Requirements  Review  and  the  Preliminary 
(or  Product)  Design  Review;  the  other  milestones  are  largely  the  same  as  for 
standard  COCOMO. 


Incremental  Development 


Software  Requirements  Review  Miiestone 
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